Conversation
|
|
||
| *For this how-to guide we have chosen the following scenario:* | ||
|
|
||
| When you tag a new release of an internal library, CircleCI automatically runs tests in the repositories that consume that library. This validates that your library changes work correctly with dependent applications before you publish the release. |
There was a problem hiding this comment.
This may be just me, but when I first read it I thought it sounded like we're saying that this already happens by default.
As opposed to - "we want CircleCI to automatically run tests..."
docs/guides/modules/orchestrate/pages/set-up-cross-repo-triggers-for-library-consumers.adoc
Outdated
Show resolved
Hide resolved
| * `pipeline.git.tag`: The tag name that was created (for tag triggers). Empty string if not triggered by a tag. | ||
| * `pipeline.git.branch`: The branch name where the event occurred in the library repository. | ||
| * `pipeline.git.revision`: The specific commit SHA from the library repository. |
There was a problem hiding this comment.
Have you tested these? I don't think they are supposed to be right. If they are, there is something wrong :(
Afaik it should be:
pipeline.event.github.ref(this is valid both TAG and for BRANCH, it just depends on which one you are pushing. But I believe it's pushed with the prefixtag/{tagname}andrefs/heads/{branchname}.pipeline.event.context.github.sha(pipeline.event.context.github.after)
Everything that is prefixed with pipeline.git.* refers to the checkout source. Here you are trying to get data from the trigger source
There was a problem hiding this comment.
👍 👍 👍 I'm going to hold off on this PR until we have documented these here
| * `pipeline.git.tag`: The tag name that was created (for tag triggers). Empty string if not triggered by a tag. | ||
| * `pipeline.git.branch`: The branch name where the event occurred in the library repository. | ||
| * `pipeline.git.revision`: The specific commit SHA from the library repository. | ||
| * `pipeline.trigger_parameters.github_app.repo_name`: The name of the library repository that triggered the pipeline. |
There was a problem hiding this comment.
This one is technically correct but we want to deprecate trigger parameters, we should use :
"pipeline.event.github.repository.name"
| ├── .circleci/ | ||
| │ ├── consumer-config.yml | ||
| │ └── other-config.yml | ||
| ---- |
There was a problem hiding this comment.
I wonder if it'd be helpful to put a screenshot of what the trigger looks like at the bottom of the table. It would render very small, but I'm assuming users would be able to click and zoom in?
There was a problem hiding this comment.
Actually, now I've read more of the page - maybe it's better suited to the tabs where you have "Option 1: Config in consumer repository" and walk the user through setting it up
|
|
||
| The trigger is now configured in CircleCI, but you also need to update your configuration file for your integration tests to run workflows for tags. | ||
|
|
||
| By default, *CircleCI does not run workflows for tags unless you explicitly specify tag filters*. |
There was a problem hiding this comment.
is it worth a link to the config guide that talks about this?
2 participants
Written with Claude code for help with structure, use case and examples
Adds a how-to guide for setting up cross-repo triggers with two pathways, one in which the config is stored with the code and one in which a centralised config repo is used.